home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20020314-20021006 / 000083_dkcombs@panix.com_Mon May 20 18:04:56 EDT 2002.msg < prev    next >
Text File  |  2020-01-01  |  1KB  |  44 lines
  1. Article: 13377 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!panix3.panix.com!not-for-mail
  3. From: dkcombs@panix.com (David Combs)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: REGET not as clever as RESEND?
  6. Date: 20 May 2002 17:47:09 -0400
  7. Organization: PANIX -- Public Access Networks Corp.
  8. Lines: 28
  9. Message-ID: <acbqst$bj2$1@panix3.panix.com>
  10. NNTP-Posting-Host: panix3.panix.com
  11. X-Trace: reader1.panix.com 1021931059 14085 166.84.1.3 (20 May 2002 21:44:19 GMT)
  12. X-Complaints-To: abuse@panix.com
  13. NNTP-Posting-Date: Mon, 20 May 2002 21:44:19 +0000 (UTC)
  14. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13377
  15.  
  16. RESEND does a pretty good job of almost instantly
  17. recovering up to the %done that it had been
  18. at when the prior transfer crapped out.
  19.  
  20. REGET seems to me so far to do a much POORER
  21. job of doing that, like recovering up to only
  22. maybe 1/3 of how far the prior get had gotten,
  23. and then rereading a whole lot of stuff that
  24. had (presumably) already been read in the prior
  25. kermit-run.
  26.  
  27. Am I the only one who has seen this?
  28.  
  29. (NOTE: I was using -i)
  30.  
  31. QUESTION: what is the SIZE of the blocks
  32. that kermit sends?  (by default)
  33.  
  34. ---
  35.  
  36. Now, kermit registers 100%, but starts getting
  37. errors (two per second) trying to get the last
  38. several bytes, it seems.
  39.  
  40. Thanks,
  41.  
  42. David
  43.  
  44.